In traditional network architecture, verifying the validity of terminal source addresses contained in messages received from a terminal can effectively prevent IP counterfeiting and spoofing. For example, counterfeiting and spoofing may occur when IP addresses included in messages sent by a terminal are manually configured. In a conventional verification process, the following principle is applied: the security checking of source media access control (MAC) addresses can be accomplished using the wireless security standard, 802.11i, and therefore, the security and validity of MAC addresses can therefore be ensured. A verifying entity (e.g., such as an access point (AP) or an access controller (AC)) establishes a source address validation improvement (SAVI) binding table entry by receiving the source addresses (e.g., the source Internet Protocol (IP) address and the source MAC address) of a terminal and saving a binding relationship between the source IP address and the source MAC address. For example, the SAVI binding table entry stores binding relationships between each terminal's source IP address and MAC address. As a result, the binding relationships stored in the SAVI binding table entry can be used to verify whether the source IP address included in the source addresses of a message that is received at a verifying entity is valid.
However, in the event that a verifying entity has no matching SAVI binding table entry for a terminal, it is unable to verify the validity of the terminal's source addresses. In this situation, conventionally, a transmission control protocol (TCP) channel is established among this verifying entity and other verifying entities to synchronize the different SAVI binding table entries stored among the different verifying entities.
For example, in a centralized wireless local area network (WLAN) architecture (e.g., that includes an AC and a fit AP), where APs serve as the verifying entities: when a terminal first goes online, the terminal launches the dynamic host configuration protocol (DHCP) by requesting an IP address from the DHCP server. AP1 intercepts the DHCP message and generates a corresponding SAVI binding table entry for that terminal and simultaneously submits the intercepted DHCP message to the AC. When the terminal roams across different ACs to AP2, AP2 searches locally and does not find a SAVI binding table entry that matches the terminal. After AP2 determines that it cannot find a SAVI binding table entry that matches the terminal, AP2 is caused to establish a channel with the AC in order to facilitate synchronization of SAVI binding table entries among different verifying entities.
In another example, in a centralized WLAN architecture, where the AC is the verifying entity: the DHCP message is intercepted on the AC and a SAVI binding table entry is generated. If the terminal roams among ACs, then a channel must also be established among the different ACs in order to synchronize the SAVI binding table entries among different verifying entities.
However, the conventional techniques used for synchronizing SAVI binding table entries among different verifying entities suffer from the need of having to establish channel(s) to perform the synchronization. Establishing the channel increases network complexity. Also, if the channel is interrupted, it becomes impossible to synchronize the SAVI table entries among the different verifying entities such that roaming verifying entities are unable to verify the validity of a terminal's source addresses. If a terminal is unable to be verified, then the terminal's messages are discarded, which impedes the terminal's ability to communicate normally.